The present invention relates to a method for conducting vehicle diagnostic analyses using distributed structure, and more specifically, to a method for accessing information necessary for conducting vehicle diagnostic analyses using a network connection and conducting vehicle diagnostic analyses based on the information obtained therefrom.
The modern automotive service bay contains numerous expensive pieces of equipment designed to automate servicing of an automobile. Wheel aligners, wheel balancers, engine analyzers, brake testers, hydraulic lifts, and similar devices typically contain microprocessors and/or computers to assist an automotive mechanic in performing various servicing tasks. Exemplary computerized automotive wheel alignment systems are disclosed in U.S. Pat. No. 4,383,370 and 5,208,646, whose teachings and disclosures are incorporated herein by reference.
Historically, such computerized automotive service equipment comprised proprietary, closed computer systems. A manufacturer of such systems would typically spend years developing software. The manufacturer had to customize the software to run on a single dedicated computer, and the resulting product had little or no flexibility to interchange and update different hardware and software elements. Each system ran different software, often on completely different operating systems designed for completely different hardware platforms. Each individual system also was incapable of being conveniently or easily updated. If a new development or improvement occurred, the manufacturer of the individual system typically had to issue an entirely new version release of the software and/or hardware in order to bring that improvement to market. The new release required a complete rewrite. Not only did new versions often take years to complete. It was also so costly to release a new system that, as a practical matter, the manufacturer would have to wait until enough improvements occurred in order to justify the financial burdens of a new version release. This hampered the ability of the end user, the automotive service professional, to bring the latest technological improvements to the customer, the typical car driver.
Furthermore, such prior art automotive service equipment systems were not generally designed to communicate or cooperate with other computers in the service bay and elsewhere. For instance,.the wheel aligner computer did not communicate with the engine analyzer computer, and neither communicated with the accounting computer or the intake/reception area computer. One consequence of this is that customer or vehicle owner/identification information had to be entered repeatedly into each piece of automotive service equipment each time the same vehicle was serviced in different parts of the service bay. This redundancy wasted valuable operator time and promoted key-entry errors.
It has been known to design automotive service equipment that sends data through a local area network to a file server, such as a Novell server platform. This, however, limits the information to being stored as files and does not support real-time data flow or a distributed application. An example of such as system is disclosed in U.S. Pat. No. 4,404,639, dated Sep. 13, 1983. The data retained in such files could only be downloaded and stored on self-contained proprietary platforms. These data-only files, then, did not give the resulting automotive service equipment system the capability of exporting data to a remote location for processing, and then returning the processed data to the original location. They also did not give the resulting system the capability to locate different portions of a single automotive service equipment application on different computers.
The prior art automotive service equipment system computers also did not communicate with any remote off-site computer to submit in real-time the data gathered by the sensors in the course of effecting a service procedure. Hence, it was not possible for sensors to transmit their data in real-time to a remote site for analysis and inspection at that remote site. For instance, in vehicle wheel alignment applications, the wheel alignment sensors that were mounted on the vehicle wheels were capable of transmitting wheel angle data only to the vehicle wheel alignment machine itself. There was no way for an off-site technician and/or an off-site computer to review the data to evaluate whether the alignment angles were within specification. Likewise, there was no way for an on-site technician to present this real-time angle information to an off-site expert for purposes of either troubleshooting problems with the servicing equipment, or for receiving instructions and advice on how to proceed with an alignment procedure.
Moreover, for automotive service equipment that depended on OEM and manufacturer generated specifications, such as vehicle wheel alignment equipment, the danger of obsolescence presented itself every new model year. Isolated, dedicated systems required continual updating of vehicle specifications, usually via CD-ROM""s. Managers of the service bay would have to maintain the most updated specifications available for their computerized automotive service equipment. Otherwise, the service bay might have to turn customers away, or worse, the attendants might service newer vehicles to erroneous specifications. The administrative task of maintaining updated specifications for the computerized equipment was an additional burden on the personnel running the service centers.
Two major developments in the computer arts have heretofore not been applied in the field of automotive service equipment. The first of these is Internet-based technologies. The second is object oriented programming. Both will be discussed below in detail to lay the groundwork for the subsequent detailed description of the present invention.
Until now, no known automotive service equipment utilized the data transfer capabilities of the Internet. The World Wide Web is one type of network residing on the Internet. It began as an information networking project at the European Laboratory for Particle Physics (CERN). The World Wide Web is best described as the specific software, protocols, conventions and information that enable hypertext and multimedia publishing of resources on different computers around the world. The popularity of the Internet has provided the computer software industry with many new software applications, yet these by and large have been restricted to home and entertainment use.
Most commonly, home and entertainment users of the Internet access the Internet through the use of a World Wide Web browser. This Web browser application can easily and seamlessly display text and graphics sent from practically any type of computer system. The information to be displayed is sent to the Web browser on Web xe2x80x9cpages.xe2x80x9d Web pages are constructed using the syntax and rules defined in the ISO 8879 Standard General Markup Language (SGML) document available from the W3 Consortium, a group of companies and individuals dedicated to the use and standardization of certain data transmission protocols. This ISO standard is sometimes known as hypertext markup language (HTML), version 3.2, although it has evolved that HTML is both slightly overinclusive and underinclusive of the actual ISO 8879 standard. HTML is a markup language used to create hypertext documents that are not unique to one platform or another. HTML files are ASCII text files with codes embedded (indicated by markup tags) to indicate formatting and hypertext links.
Computer systems that send information to a Web browser are called Web servers. A Web server stores Web pages (constructed and stored as static files) and serves them out to the Web browser on demand. In their simplest form, server Web pages that are constructed only with HTML, without more, cannot be changed by a Web browser user, and are thus not interactive.
Those of skill in the art will appreciate that the Web utilizes a number of communication protocols to transmit and receive addressable data. HTTP is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol. Web servers are computers equipped with the server software to respond to HTTP requests, such as requests from a Web browser. HTTP has generally subsumed most of the functions of the older File Transfer Protocol (FTP). FTP, in turn, is a protocol that requires a logon to a remote computer to browse directories and effect a two-way file transfer. A feature of the newer HTTP, which again has largely replaced FTP, is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
A Web server uses this HTTP protocol to communicate with clients on a TCP/IP network. TCP/IP is a lower level protocol that communicates with a network card driver. The network card driver in turn communicates directly with the network hardware or physical layer of the protocol stack. TCP/IP provides the source and destination address of the data. More specifically, TCP/IP is defined as a set of networking protocols that provides communications across interconnected networks of unlike computers. TCP/IP includes standards and conventions for routing data traffic. When a user at a browser submits a new request to access a Web page, one of the first things the browser does is to locate the TCP/IP address for that particular page. In principle, any computer having a TCP/IP address and properly connected to the Internet can be accessed on the Web.
By using a single Web browser application to access different Web xe2x80x9csites,xe2x80x9d or Web Servers, around the world, a user can see, hear and interact with many different informational systems. A user can experience information in different languages and presentation styles. A user can view pictures, movies, music, live telephone or video teleconferences, search databases, download software, control and view robotic video cameras, participate in group discussions, and send or receive email. A special new browser, called a thin client, can also run computer software that actually resides on another computer across the world. Such thin clients make it possible to lease software or run software that would not normally work on a particular type of computer, i.e., Windows programs on a Unix system. An example of a thin client is the Winframe Web Client by Citrix Systems, Inc., Coral Springs, Fla.
At the Web server, oftentimes an application exists that receives data inputs from a Web browser, and then uses those inputs to dynamically assemble a particular output in return. The Web browser then displays the output to the browser operator. These applications are generally referred to as common gateway interfaces (CGI). A CGI script file is a program that executes on the Web server. A database search engine is a good example of a CGI script, as is a Web page counter that indicates the number of xe2x80x9chits,xe2x80x9d or visitors, to a Web page within a certain period. The user at the Browser is first presented with a form inquiring what type of information is to be extracted from the database. Once the user fills out the form and submits it by sending it back to the Web server, the CGI script is executed. The CGI uses the information from the form to compose a query to the database. The CGI script then formats the information retrieved from the database query and sends it back to the Web browser for display. A CGI script is limited, since it is basically a stand-alone program that executes outside the Web server. CGI scripts cannot access user information available from within the Web server, as they can usually only take an input directly from the form submitted by the user at the browser.
Other programs reside on the browser alone, or the browser and server both, to add to the functionality of the browser by making it dynamic and interactive with the Web server. Two examples are Java and ActiveX.
Java, developed by Sun Microsystems, is a browser language that allows small programs or applications, called xe2x80x9capplets,xe2x80x9d to run within the browser. Java script is sent from the Web server as byte codes. The Java byte codes are not HTML but are embedded within HTML. The Web browser contains a program called a Java Virtual Machine that converts the byte codes to computer instructions that are subsequently executed. Java is therefore computer type independent, and a Java applet will work on any Web browser supporting the Java Virtual Machine. Java is good for animated displays and moving or scrolling text messages, but is limited to only the functions provided by the Web browser. A Java applet cannot access functions outside the Web browser.
The Component Object Model (COM) is a software object model that has a standardized interface. COM objects can communicate with other COM objects over distributed computers via protocols such as DCOM, a Microsoft standard. The protocol is indifferent to the particular transmission medium used, i.e., LAN, Intranet, Internet, serial connection, et cetera.
ActiveX Technology, developed by Microsoft Corporation, is an implementation of a component object model. ActiveX is similar to CGl scripts and Java applets. ActiveX enables interactive and fully functional programs based on Web browser technology. ActiveX is made up of several components: ActiveX server extensions, server filters, Active server pages and ActiveX controls (formerly, OLE controls). ActiveX server extensions are similar to CGI scripts but actually execute as extensions of the Web server. Extensions have access to useful information, within the Web server, about the Web browser users and the Web server host system. ActiveX controls are analogous to Java applets. Examples include buttons, stock tickers and chart controls. However, unlike Java script, ActiveX controls are not byte codes but actual small computer programs, or software objects that do not require a subsystem such as the Java Virtual Machine. Active X controls are not computer type independent and must be written exclusively for a target computer type, e.g., a Windows-based system. Once installed into the Web browser, an ActiveX control is not limited to only the functions provided by the Web browser. Active X controls have the power to perform any function that any typical computer application can perform because they are stand alone software objects. For instance, they may be a stand alone word processor, spread sheet, etc. ActiveX controls also have the built-in capacity to share data with other Active X controls or extensions on the same computer or one on a remote computer system. Other ActiveX technologies such as ActiveX server pages and ActiveX server filters provide a comprehensive development system for Internet and Web browser based systems.
In sum, HTTP is the basic underlying protocol for HTML, CGI script, Java applets and ActiveX controls. FIGS. 1-3 show the three basic Web servers and Web browser configurations. FIG. 1 shows an inactive model of a typical HTML-only based environment. Web server 10 provides HTML based Web pages to Web browser 20, the HTTP client. No animation or browser-controlled output is possible because neither CGI scripts, Java nor ActiveX is implemented.
FIG. 2 represents the active server model, and shows enhancements to the basic model of FIG. 1. In this model, Web server 30 is an active server, providing dynamic information on Web pages, HTML-based database access, and CGI-style programs. Web browser 40, the HTTP client, continues to be inactive and only display what is sent by the Active server, but now the Active server model offers programmable extensions to the server software that are similar to CGI scripts. These extensions execute in the same address space as the server software, and have access to all the server system resources, providing much faster response time than CGI programs.
FIG. 3 represents the next evolution, the ActiveX model. It shows additional communication between the Web server 50 and the Web browser 60 other than just HTML. In this model, ActiveX controls on the Web browser 60 communicate directly with ActiveX controls on the Web server 50. ActiveX controls are software objects or somewhat self-contained programs that can be contained within other programs called container objects 55. Internet Explorer 4.0 (a Web browser), Microsoft Office Binder and the present Windows shell are all examples of ActiveX container objects 55.
One example of an ActiveX control for the Web browser is Microsoft""s ActiveMovie Control. ActiveMovie Player is an ActiveX control that can view files that contain both audio and image information. The key advantage is that you can produce streaming multimedia content that the user can immediately enjoy, rather than waiting for a multimedia file to be first downloaded. ActiveX technology provides for on the fly Web browser updating. If the Web browser does not initially support ActiveMovie, for example, the Web server will update the Web browser by sending the ActiveMovie component via HTTP. The Web browser will transparently install ActiveMovie and retain it for future use. The ActiveMovie component executes as part of the Web browser and extends its capabilities to play real-time sounds and images. While playing a movie, the communication is no longer HTML, but direct communications between the ActiveMovie ActiveX control on the Web server and the ActiveMovie ActiveX control on the Web browser. Hence, ActiveX controls are not limited to Web pages. They may be used as software objects within a standard non-networking application. Such reusability allows a program to be constructed as a stand alone non-networking application and then easily extended to share information with remote computer systems.
The second computer development that is not known to have been applied in the field of automotive service equipment is object oriented programming and object oriented design (OOP/OOD). OOP involves the creation of software xe2x80x9cobjects.xe2x80x9d The foregoing description of Internet technologies referred to such objects, because current Web browser/server technology relies heavily on them. More generally, however, software objects may be thought of as self-contained mini-programs within a program. Before OOP, programs primarily consisted of two basic elements, data and program instructions. Data elements are storage locations. Program instructions are commands the computer will follow to make decisions or manipulate data. A data element such as a variable, constant or structure had only one functionxe2x80x94to hold information. Instructions had only one functionxe2x80x94to perform some action. With the advent of software objects, the line between data and instructions becomes fuzzy. Objects are software entities that have properties. They can take action, like instructions, but also utilize data. One of the main virtues of software objects is their inherent reusability. Objects, being largely self-contained, may be purchased that perform many commonplace functions, such as database routines, mathematical algorithms, and input/output functions. Many objects are included with the Microsoft Visual C/C++4.2 Developers Studio, an integrated software development environment for writing object oriented programs.
Object oriented applications are generally easier to create and modify than non-object oriented applications. If a portion of an application must be changed, all that is necessary is to change the particular software object in question. The modification will be transparent to the rest of the application. This is in contrast to prior systems in which an entire application had to be rewritten and debugged whenever a minor change was made to a single part of the application.
Object oriented programs also do not have to reside completely on one computer. As long as the object can be accessed, the computer running the main application routine will be able to call the object and operate on it. A computer running a main application routine might use the HTTP protocol to retrieve an object from a computer having a known TCP/IP address. In sum, OOP allows the transition from monolithic closed systems to distributed open systems.
In accordance with one aspect of the invention, a method for conducting a vehicle diagnostic analysis comprises the machine-implemented steps of executing a software application for conducting the vehicle diagnostic analysis, receiving signals representative of parameters of a vehicle, accessing a software object over a data transmission network, the software object containing information necessary for conducting the vehicle diagnostic analysis, and determining a vehicle diagnostic state based on the signals representative of the parameters of the vehicle and the information contained in the software object.
In one aspect, the method further comprises the step of displaying the vehicle diagnostic state. In another aspect, the method includes calculating a usage fee based on the number of times the software object is accessed.
Since the information necessary for conducting the vehicle diagnostic analysis is distributed in different systems connecting to each other with a data communication network, a local automotive service system can minimize the size of software stored locally and can access most of the information and/or algorithm required to conduct the vehicle diagnostic analysis from a remote system. In addition, updates of the information can take place seamlessly without affecting the local system. The remote system that allows information access by other systems can calculate usage charge based on a peruse basis.
Additional advantages and novel features of the invention will be set forth in part in the description with follows, and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention.